(12) 



UK Patent Application ,, S ,GB ,,,,2328532 „ 31 A 



(43) Date of A Publication 24.02.1999 



(21) Application No 980190&0 

(22) Date of Rling 30-01 1998 



(71) Applicant(s) 

International Business Machines Corporation 

(Incorporated in USA • New York) 

Armonk, New York 10504, United States of America 

(72) Inventorts) 

John Martin Henley 
Stuart Currte 
Phifip James Atkin 

(74) Agent and/or Address for Service 
CBoyce 

SM United Kingdom limited; Inteliectual Property 
Department Mail Point 110, Hursley Parle 
WINCHESTER, Hampshire, S021 2JN, 
United Kingdom 



(51) 


INT CL 6 




G06F 17/30 9/30 


(52) 


UICCL (Edition Q) 




G4AAAPAPX 


(56) 


Documents Cited 




US 4280193 A 


(58) 


Field of Search 



UK CL (Edition P ) 04A AFGOC AFGOX APX 
INTCL 6 G06F 9/48 13/38 17/30 
ONLINE: WP|, INSPEC. COMPUTER 



(54) Abstract Title 

Peripheral controller for an Internet transaction processing system 

(57) Transaction processing system for a web ATM (fig. 5) which includes a browser 80 running a web 
application comprising one or more web pages, e.g. Page_1.htm. Transaction manager 20 is responsive to 
transaction requests from browser 80, and a set of service provider modules SPM (30 and 37, figs. 1 and 2) 
relay these transaction requests to the appropriate hardware modules (14, figs. 1 and 2) for execution A 
»r'£TJ ^ 0OmpOnent 90 ' is insten «««» *°m a web page in the application, and includes means 
ai!' * *l commun,cat,n S t"e transaction requests from the web application to transaction manager 20 
Also described are a shared memory controller component 60". also instantiated from a web page in the 
application and which enables information to be kept available and secure when the user swaps between web 
pages by means of shared memory 64. and a security module 95' which enables the control of access to 
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A PBRIPHBRAL CONTROIiLBR POR A TRANSACTION PROCESSING SYSTEM 

The present invention relates to a peripheral controller for a 
transaction processing system. 

woSA/XFS {Windows Open Services Architecture for Extended Financial 
Services) is an emerging standard enabling financial institutions, whose 
branch and office solutions run on the windows NT platform, to develop 
applications independent of vendor equipment. 

Figure 1 shows the standard WOSA model. Using this model, an 
application 10 communicates hardware requests 12 to various hardware 
devices in an ATO 14 via a WOSA manager 20. The application issues 
transaction requests 12 which are hardware independent, and thus vendor 
independent. The requests are queued by the WOSA manager 20 which manages 
concurrent access to the ATM hardware 14 from any number of 
applications 10* 

when a piece of hardware is installed on the ATM, it registers its 
controlling software, known as a service, provider module (SPM) 30, with 
the WOSA manager by using, for example, the Windows registry. The WOSA 
manager 20 is thus able to relay a hardware request 12 to an appropriate 
SPM 30, using the windows registry as a look-up table. The SPM 30 takes 
relayed hardware independent requests 16 from the WOSA manager and 
actuates the appropriate piece of hardware to process the requests. The 
results of a request can be returned by an SPM 30 synchronously via the 
WOSA manager 20 or asynchronously by generating a windows event, 

A number of companies other than the Applicant, including Microsoft 
Corporation, Keybank incorporated of Cleveland, Ohio and Diebold 
Incorporated of Canton, Ohio have mooted the idea of using an automatic 
teller machine (ATM) to provide access to Internet services, for example, 
for executing financial transactions, ticket reservation and information 
retrieval. 

It is an object of the present invention to provide a transaction 
processing system for a web ATM. 

Accordingly, the present invention provides a transaction 
processing system for a web ATM including an Internet browser adapted to 
run a web application, the web application comprising one or more web 



pages, said transaction processing system including: a transaction 
manager running in a first process; a peripheral controller component 
adapted to be instantiated from a web page, said peripheral controller 
including means for communicating transaction requests from said web 
application to said transaction manager; and a set of service provider 
modules, each service provider module being adapted to relay transaction 
requests passed from said transaction manager to an associated hardware 
module. 

In a second aspect the invention provides a peripheral controller 
component for a transaction processing system in which a transaction 
manager runs in a first process and is responsive to transaction requests 
from a browser adapted to run a web application, the application 
comprising one or more web pages, and a set of service provider modules 
are adapted to relay transaction requests passed from said transaction 
manager to an associated hardware module for execution? said peripheral 
controller component being adapted to be instantiated from a web page and 
including means for communicating transaction requests from said web 
application to said transaction manager. 

preferably, said peripheral controller component comprises t a first 
layer comprising means for enabling a web application to initiate a 
transaction request; and a second layer comprising means for dividing 
said transaction request into components and for communicating said 
transaction request components to said transaction manager. 

Further preferably, said first layer includes means for controlling 
an area of memory associated with said peripheral controller and means 
for selectively instantiating said second layer, on a first instantiation 
of the peripheral controller, said memory controlling means being adapted 
to control said area of memory to relay transaction request information 
to and from further instantiations of said peripheral controller. 

In a further aspect the invention provides an ATM including the 
transaction processing system according to the invention. 

Embodiments of the invention will now be described with reference 
to the accompanying drawings, in which: 



Figure 1 shows a standard wosa single process transaction 
processing system including a security module according to an aspect of 
the invention (shown shaded) ; 

Figure 2 shows an alternative transaction processing system 
including a security module according to an aspect of the invention 
(shown shaded) ; 

Figure 3 shows a server component of the transaction processing 
system of Figure 2 in more detail? 

Figure 4 is a schematic view of a portion of a Windows NT registry 
employed by a WOSA manager; 

Figure 5 is a schematic view of a set of web ATMs including a 
transaction processing system according to an aspect of the present 
invention; 

Figure 6 is a schematic view of a set of internet Applications 
employing a peripheral controller component and a security controller 
component operable with the transaction processing system according to 
the present invention; and 

Figure 7 is a detailed schematic view of a peripheral controller 
component of Figure 6. 

The standard WOSA model includes three layers, Figure 1. An 
application layer 10 issues transaction requests in the form of hardware 
independent Application Programming Interface (API) calls 12 to a WOSA 
Manager 20 layer in order to access services from a Service Provider 30, 
37 layer. All components exist within the same process (the 
Application's) and memory address space* 

WOSA is a classic single process model, where all components of the 
solution run in the same process. If a single thread within this process 
abends, it will normally take the entire process down. Although this is 
acceptable in non-critical applications, for example printing, it is not 
acceptable where security is involved and where detailed audit trails are 
required. The best example of this case is where ATO cash dispensing is 
involved. If the process abends while a dispense is taking place, the 
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error needs to be recoverable in order to determine the disposition of 
the cash involved. 

In an alternative server model. Figure 2, the application 10 and 
WOSA Manager 20 exist within the same user application process. The WOSA 
manager 20, however, communicates with stub Dynamic Link Libraries (DLLs) 
35 each corresponding to a respective SPM 30 of Figure 1. Transaction 
requests 12 from the application layer 10 pass through the WOSA Manager 
20 to the stub DLLs 35, where the data is repackaged and passed across 
process boundaries to a server 40 running in a separate process, where 
the required transaction request is actually executed. The server 40 
communicates with SPM'S 30 to execute the transaction request, and any 
execution results are either passed back from the SPMs to the application 
10 through the WOSA manager 20, via the stub dlls 35, or via an operating 
system messenger 50. in a windows NT operating system embodiment of the 
invention, the SPMs 30 generate windows events using an application 
nominated window handle, whereas in an embodiment of the invention using 
IBM's OS/2 operating system, the SPMs generate presentation manager 
events to communicate directly with an application 10. 

The method of response is determined by the application 10, 
depending on whether a transaction request issued is specified as 
synchronous (the server responds through the stub DLL mechanism) or 
asynchronous (the server responds via the windows Event mechanism) . 

information is also accessible by both the application 10 and the 
SPMs using shared memory. When, for example, an SPM 30 wishes to transmit 
information to an application 10, the SPM sends a WOSA call to the wosa 
manager 20 which communicates with an operating system memory manager 55 
to allocate the shared memory. Once allocated, then SPMs 30 in the server 
40 process or applications 10 can read or write information from this 
shared memory. 

Figure 3, shows the server 40 in more detail. The server is a 
multi- threaded application supporting the simultaneous execution of 
transaction requests on all of its supported WOSA device classes 
explained below. The server 40 consists of the following major 
components : 

A server object 41 runs in its own thread and has responsibility 
for creating and monitoring memory 'pipes' 42 connecting the server 



process to respective stub DLLs 35, running in the user application 
process, when the server object detects a transaction request packet from 
one of the stub DLLs 35 waiting in its associated 'pipe' 42, it moves the 
packet into a master Queue 43 and thus frees the pipe for more 
communications . The server also detects packets in the master queue 43 
that are response packets from service provider modules 30, and channels 
these back through the 'pipes' to the correct stub DLL 35, which then 
passes the response back to the user application 10 via the wosa Manager. 

The memory pipes 42 are implemented in a class including 
essentially three methods: readPipeO, writePipeO, queryPipeO with the 
methods being passed an identifier corresponding to the stub DLL 
associated with the pipe. In the application process, a stub DLL 35 
receives a WOSA transaction request from the transaction manager and 
calls the writePipe method to place the request in its pipe 42. writePipe 
essentially writes a message to a designated location in shared memory 
with a flag indicating that the message needs to be read. Once the stub 
DLL 35 has written the message to the pipe, it then polls its pipe 42 
continually using querypipe to determine when a response has been sent 
from the server 41 or if the message has. been read. 

Within the server process, the server object 41 continually polls 
each of the pipes 42 using the querypipe method for each pipe in turn to 
determine if messages are waiting to be processed. If a pipe has a 
message, the server calls readPipe to read the message from the pipe, 
resets the message flag indicating that the message has been read and 
places the message in the master queue 43. The server also interrogates 
the master queue 43, and if a message for the server 41 is in the master 
queue 43, the server 41 pops the messages from the queue and calls 
writePipe to place the message in the appropriate pipe and thereafter 
reverts back to querying the pipe for the next message. 

A client object 44 runs in its own thread and is responsible for 
creating and managing the supported service provider modules 30 below it. 
The client object 44 monitors the server master queue 43 and when it 
detects an inbound packet for one of its managed hardware devices, it 
moves the packet from the queue 43 on to a private queue 45 associated 
with a target device. 

Instances of service provider module objects 30 are created at 
startup time by the client. In the case of an ATM, objects would be 
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instantiated for a journal printer, receipt printer, passbook printer, 
statement printer, deposit unit, cash dispenser, magnetic card reader / 
smart card reader, sensors and indicators unit, pinpad unit, encryptor 
unit, vendor dependant mode (vdm) unit, and text terminal unit. Each 
5 instantiation spawns its own control thread that is responsible for 

monitoring its own private queue 45 for requests that are placed there by 
the client object 44. When an SPM object 30 detects a request waiting on 
its private queue 45, or if there is a request pending execution and it 
is time to attempt to process pending requests again, the SPM object 

10 spawns an execution thread that handles the execution of that single 

request. The execution thread has the responsibility of processing the 
request to its conclusion, either returning the relevant data to the 
caller application 10 via events, marking the request as 'pending' on the 
queue 45 and completing, or returning a response by returning a completed 

15 . packet back to the server queue 43 for transmission to the stub DLL 35 

associated with that hardware device. 

Bach SPM 30 converts all WOSA transaction requests into one or more 
generic commands that are processed by a layer of small hardware DLLs 46. 
An Application Programming Interface (API) for each type of hardware 
device is published by the hardware vendor and consists of the minimum 
number of hardware level commands {example read_card on a magnetic stripe 
reader device, or dispense_cash on a dispenser) that can satisfy the 
complete set of WOSA transaction requests for that device type. For 
example, a respective hardware DLL is supplied for both an IBM Dispenser 
and an Olivetti dispenser. The user only has to change which DLL is 
active, by updating the windows registry in order to switch between the 
different devices. At the application and server layers, nothing changes. 
The same is true for all device types. 

The windows NT registry is a hierarchy of keys. Figure 4, each key 
containing one or more data values. The WOSA Manager 20 uses the system 
provided HKEY_CLASSES_ROOT key to store and obtain data on Logical 
service Providers, for example, -msrspm-. The application 10 opens a 
35 service by providing the WOSA manager with that services' logical name. 

The manager finds the key entry, -msrspm- in the 

HKEY_CLASSES_ROOT\WOSA/XFS_RO0T\LO6ICAL_SERVICES key for that service. 
One of the data fields, -provider", within that key is an entry 
describing the service provider key name, "testmsr". The manager then 
40 accesses the relevant service provider key within the 

HKEY_CLASSES_ROOT\WOSA/XFS_ROOT\SERVICE_PROVIDERS key, which will contain 
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an entry describing the exact path to the physical ail that contains the 
executable code for that service provider, B d: \pa th\msrdll.dll *\ 

In the conventional WOSA transaction processing system of Figure 1, 
the path to the physical file in the Windows registry will point to a 
service provider module 30. For service providers who support the 
alternative server model of Figure 2, the path points to a stub DLL 35. 
This stub DLL 35 will thus direct any WOSA transaction requests across 
the process boundary to the server 40 as described above. If some vendor 
devices do not support the alternative server model, because they do not 
provide stub modules, then their respective SPMs can communicate directly 
with the WOSA manager 20 within the same process, as in the case of the 
SPM 37 in Figure 2 (the filter 36 can be ignored for the moment and will 
be explained later) . 

The above description has extended only to traditional applications 
running on an ATM. There exists a demand now for ATMs to provide more 
than simply banking services by enabling users to conduct all types of 
transactions on an ATM. Figure 5 shows a web ATM (Automatic Teller 
Machine) which includes a PC compatible computer or at least a computer 
of this power, appropriate Internet browser software 80, for example 
Internet Explorer from Microsoft, compatible ATM operating system 
software 100 for example windows NT from Microsoft and a transaction 
processing system according to the model of Figure 1 or Figure 2. The ATM 
may have a touch screen or function buttons (not shown) allowing a 
sophisticated level of interaction between the user and an ATM 
Application. In the present embodiment, the browser 80 takes the place of 
the application 10 of Figures 1 and 2, and runs a Bank AIM Application 
written in the form of a page, Pagei_l.htm, or series of pages located on 
a bank web server 74 (or cached on the local machine) . The bank 
application, via its web pages, can prompt a web ATM user to swap web. 
pages within the bank web site or to swap to web pages of any other web 
sites, for example, an airline web page, Page_2.htm, located at an 
Airline Web Server 70 or a supermarket web page, Page_3.htm, located at a 
Supermarket web server 72. 

In a web ATM, there is a requirement for such Internet Banking and 
Financial Services Applications, to keep information (such as account 
details, PIN numbers etc.) available and secure when a user swaps between 
web pages. The user may swap pages within a site, for example, when 
conducting on-line banking and swapping from one account transaction to 
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another; or when a user swaps between pages on different sites such as 
from their bank's web site to a utility, supermarket or airline web site. 
It is important, if such inter- or intra-site commerce is to be 
conducted, for data relating to the user to be persistent between web 
pages, because requesting the user to enter a card number or PIN multiple 
times is not viable from a usability viewpoint. 

The present embodiment provides a ACTIVEX or JAVABEAN memory 
controller component 60 that can be attached to a web page written using 
the JAVASCRIPT or VBSCRIPT extensions to HTML (hyper- text mark-up 
language) , or the JAVA language, to store and retrieve variable data, in 
either secure (encrypted) or insecure (clear) modes- Other web pages, 
that can reside on other servers, can also access this data via their own 
instance of the memory controller component, providing an easy to use and 
secure method of transferring sensitive data between pages. 

The memory controller 60 will be described in terms of ActiveX 
controls for an Internet Explorer web browser from Microsoft, although it 
will be seen that the invention is applicable to other languages, web 
browsers and operating systems, for example, JAVA and JAVASCRIPT, 
Netscape and OS/2. 

Turning now to Figure 6, the memory controller component 60 
manipulates an area of shared memory 64 allocated by a first instance of 
the component 60' and manipulated by subsequent instances of the 
component. The component can be instantiated directly from a HTML file, 
or alternatively as with the instances 60', the component can be 
instantiated from a script file, for example, layoutW.alx which in turn 
is included in Page_l.htm or PageL^.htm. Including a script file in a 
HTML file can be achieved, for example, by using the following syntax: 

<0BJECT CLASSID="Clsid:nnnnn ID*"Html__Layoutl" STYLE -LEFT: Opt ;TOP:0pt"> 

<PARAM NAME=«ALXPATH" REF VALUB="d:\ \layOUt#l .alx«> 

</OBJECT> 

The CLASSID attribute specifies the type of component that is to be 
loaded: "clsid: n indicates an ActiveX control; whereas "java:" would 
indicate a Java applet, "clsid:" is followed by an ActiveX control's 
registry key number "nnnnn". This key uniquely identifies the particular 
ActiveX control and is the same on every windows' 95 and windows NT 4 
machine. <PARAM. .> tags are parameters, passed to the ActiveX control, to 
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determine, for example, how the control is to present itself, in this 
case the ActiveX control "nnnnn" for laying out a page is passed a 
reference to the location of the script file layout#l.alx located on a 
local D: drive on a machine running the browser. 

5 

In either case, the syntax for instantiating a memory controller 
component 60, in this case called MemoryCantrol , from either the HTML 
file or the ALX file is, for example: 

10 <OBJECT ID="MeraoryControl" CLASSID="clsid:xxxxx 

STYLE "TOP : Opt ; LEFT : Opt ; WIDTH : 7 5pt ; Z INDEX : 0 ; " > 

<PARAM NAME= > 

</OBJECT> 



In this case "xxxxx" represents the key number for the memory 
controller ActiveX control. This control 60 resides in an .OCX file on 
the local disk on the browser machine and is registered for use with any 
web pages that need to use the memory controller, it should therefore be 
seen that, in the ActiveX embodiment, the script file or html file only 
includes references 60' to the memory controller or any of the other 
Controls a, b or c, and that the software for the controls is actually 
stored on a local disk. In an JAVA embodiment, however. Applets are 
downloaded every time a page is accessed. 

Instantiation of an ActiveX control exposes a number of methods, 
which can be called from within the HTML file or the ALX file, by 
prefixing the name of the method with the OBJECT ID, Thus, a method is 
called using the following sample syntax: 

<SCRIPT LANGUAGE 53 " JavaScript" FOR "Enable" EVENT="Click() "> 
<!-- 

MemoryControl . abed = 1; 
//--> 



where "abed" is the name of the method. In this example, a button called 
"Enable" has a "click" event. The button could, for example, be any one 
of Controls a...c included in a web page using the <0BJECT> tag described 
above. The button is displayed when the HTML page is downloaded and, when 
clicked by the user, calls the method "abed", setting its state to "1". 
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The methods exposed by the memory controller according to the 
present embodiment are as follows: 
Connect (Newvalue) 

SetVariable (variableName, valueName) 
Getvariable (variableName) 
S tor ekey ( KeyNumber , Keyvalue) 
SetvariableBnc(VarName. ValueName, KeyNumber) 
GetVar iab 1 eEnc ( varName , KeyNumber) 
BncryptKeyiKeyTarget, KeySource) 
DeleteAll () 
DeleteKey (KeyNumber) 

Connect is passed a variable NewValue. This has a value "1" to 
indicate a web page wishes to connect to shared memory 64 and a value »0« 
to indicate a web page wishes to disconnect from shared memory. When 
connect is called with NewValue^l-, it first checks to see if a heap 
manager program 62 has been instantiated, if not the heap manager is 
instantiated. The heap manager, when instantiated allocates a named area 
of shared memory, in the present embodiment 4Mb in siae. In Windows NT, 
this iB done using a system call "CreateFileMapping" , whereas in OS/2 two 
system calls are needed, -DosAllocSharedMem- to check if the named memory 
has been allocated and -DOSGetNamedSharedMem" to allocate the named 
memory. 

The named shared memory 64 contains a component control block 
(CCB) , plus a large area of 'heap' space 66 to store data. The CCB is 
mostly taken up with an array of control structures that specify details 
of individual variables stored by the component. Each structure contains: 

1. The name of the variable, up to a finite length. 

2. The length of the variable data (for encryption) 

3. A control flags field for internal usage. 

4. An internal offset pointer to where the data resides. 

space is allocated for a finite number. Max Entries, of these 
structures, preferably several thousand. The' heap manager 62 preferably 
allocates the space using a virtual memory page file of the operating 
system, so that efficient management of the memory used, ie. paging in 



and out of physical memory, is under the control of the native operating 
system. 

Once the heap manager 62 is instantiated, the connect method can 
check a reserved field in the CCB. If this field contains a pre- 
determined string value, then connect knows the CCB has been initialised. 
If not, then the contents of the CCB array is cleared. 

Further instantiations of the shared memory controller 60 will also 
seek to connect their respective web pages to shared memory 64, in these 
cases, however, when connect is called, the further instantiation will 
see that the named shared memory has been allocated and so all these web 
pages need is the start address of shared memory 64. Each web page 
application can then call the remaining methods to manipulate the shared 
memory 64 as required. 

SetVariable is used to store variables in unencrypted format. 
Variables are stored or retrieved by setting the VariableName and 
ValueName parameters and calling SetVariable. ValueName, ie. the variable 
data, is preferably passed as an ASCII string, terminated with a null 
character. SetVariable checks the validity of the properties and if 
acceptable, the CCB array is checked to see if a variable of that name is 
already in existence, if it is, then the memory already allocated to the 
existing data is freed and a new allocation request is made to the heap 
manager 62 for a memory block of the size required to hold tbe new data. 
The heap manager 62 allocates memory from the heap 66 of shared storage 
and its real address is modified to show just the offset from the start 
of shared memory 64 storage. It is this offset which is tben stored in 
the CCB array. 

This technique is employed because the shared memory 64 may not 
exist in the same address location in the different web page processes 
that attach to the shared memory 64. The 'real' address of any specific 
variable data will therefore be different for each process, however, if 
each process knows what the base address of its instance of shared memory 
is, its instance of the memory controller component 60 can calculate at 
run time what the 'real' address of the required variable data is by 
adding that to the stored offset of the variable data in the CCB. 

GetVariable is the retrieval method corresponding to SetVariable. 
By simply setting VariableName, GetVariable can search the CCB for the 
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variable's offset address within the heap 66 and return the variable data 
at this address in the form of a string to the calling script. 

StoreKey stores keys used by other methods as volatile keys (ie 
they cannot be saved and are not persistent) in binary format in the 
Windows NT registry HKE Y_CLAS SES_*OOT key, using a non -obvious 
nomenclature within the key. Keys are stored as binary values, but are 
passed into StoreKey as a hexadecimal representation in ASCII, ie 
"0123ABCD". StoreKey then manipulates the data into binary 0xO123ABCD 
prior to storing the key in the Windows registry. 

It will be seen that, because they are volatile, any stored 
encryption keys will be lost once the local machine is turned off. Thus, 
a page can set encryption keys on the local machine during a browser 
session with little possibility of the keys being recovered by 
unauthorised users. 

It will be seen that where hardware encryption can be used, 
encryption keys would be stored in the physical device used for the 
encryption functions. 

SetV&riableBnc corresponds to SetVariable but is used where data is 
to be encrypted before being stored in shared memory 64. The KeyNumber 
property is set to the required encrypt key number prior to calling 
SetVariableEnc. In the case of an encrypted variable, the process is the 
same as for Setvariable except that the variable data is encrypted or 
decrypted using either the DBS or RSA algorithms and the key specified in 
the KeyNumber property prior to calling the encrypt method. 

OetvariableBnc allows a script to recall encrypted variables, by 
setting the KeyNumber with which the variable was encrypted. If the 
incorrect key number is used then garbage will be returned, or if 
Getvariable is used to try and recover an encrypted variable, a null 
value will be returned. 

Bncryptkey allows the user to encrypt or decrypt keys multiple 
times prior to their use. There are no methods for retrieving keys, so a 
potential hacker would have to have access to the local machine the 
memory controller component was running on in order to stand any chance 
of finding the encryption keys in use. 
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DeleteAll deletes all encryption keys from the Windows registry and 
DeleteKey deletes the key specified by ReyNumber. 

Using the shared memory controller enables smooth inter-site 
electronic commerce. For example, page_l.htm, a bank web page, can be 
designed to take a user's account details and verify the user's identity 
by, for example, getting the user to set PIN number or other secret 
details, which can be stored in singly encrypted or multiply encrypted 
format on a local machine. It should be noted that at this stage the 
user's information need not be transmitted to the bank and can remain 
only on the local machine, a™#1_.# 2 for access at a later time by bank 
web pages or web pages from other compatible sites. 

The user can be prompted by the bank web page to swap web pages 
within the bank web site or to swap to web pages of any other web sites 
who also employ a shared memory controller according to the invention. 
The pages for these web sites can now look at any data set by the user 
when at the bank web page and can, for example, verify to the other web 
site that the identity or the credit limit of the individual is valid. It 
will be seen that, unlike the 'cookie' protocol, the domain name of the 
web server for other sites from which, for example, Page_2.htm is 
received, need not be related to the domain name for bank site from which 
Page_l.htm is received. 

In the present embodiment, at least one page of the bank ATM 
application will include a reference 60' to the controller 60 to connect 
the browser to shared memory 64 and expose the methods described above. 

Each ATM#l...z further includes at least one further ActiveX 
control 90 which, when referenced in a web page 90', exposes methods for 
controlling ATM peripherals (not shown) such as a printer, keypad, 
magnetic stripe reader etc. 

Each peripheral (device) controller object consists of two layers, 
an upper component layer 96 and a lower device layer 98 compiled either 
as an ActiveX Control or Javabeam component according to the 
implementation environment. Figure 7. 

The lower device layer 98 is designed to remove the con&lexities of 
WOSA functions from an application developer. Executing a WOSA 
transaction request can entail making a series of WOSA function calls, 



when in fact an application developer might simply wish to, for example, 
"read a pin number" or "write to the display". The device layer: provides 
a class hierarchy that encapsulates all wosa device functions into a 
simpler interface 99; handles the windows messaging environment by 
maintaining a private queue 101 for the peripheral to store events 
retrieved from the operating system messenger 50; and breaks down complex 
WOSA data structures into more readily manipulated data blocks. The 
methods 99 exposed by each peripheral controller's device layer are 
utilised by the associated component layer 96 to provide device functions 
102 for instantiations of ACTIVEX or JAVABBAN peripheral controller 
components within a web page, Page_l.htm or Page_2.htm. 

The upper component layer 96 includes: a) pipe manager 103 which 
manages a shared memory control block 104 associated with the peripheral 
control, utilising the memory 'pipe' class, explained in relation to the 
server 41 and stub modules 35 above (This allows different processes, ie. 
web pages, having different instantiations of the same peripheral control 
to access the same piece of data to monitor or initiate transaction 
requests) ; and b) an interface 105 to the device specific methods of the 
device layer. 

When a second instance of a peripheral control is instantiated from 
another web page, it's contractor determines that a shared memory control 
block 104 has been initialised by the first instance of the control. In 
this case, the second instance does not instantiate a device layer 98, 
rather it sia«>ly instantiates a memory pipe object 103 to read, write and 
monitor the shared block 104. 

A separate thread monitors the event queue 101 for a device and 
fires device specific events to the component layer when an event message 
is received from the operating system messenger 50. The shared memory 
block 104 is utilised to keep accurate track of the status of the device, 
as each web page that utilises the component will have a different 
instance of the component layer 96, though the device layer 98 is only 
instantiated once. Any status change is therefore available to any of the 
instances of any peripheral controller. 

in operation, the ATM Application pages include an appropriate user 
interface, so that a user is first prompted to insert a card into the 
magnetic stripe reader. The ATM Application pages are able to call 
methods exposed by peripheral controllers 90 for reading the users card 
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and PIN number, for example, thus verifying the user's identity. The ATM 
Application can write information to shared memory 64 such as the user's 
available credit limit using methods exposed by the shared memory control 
60, as well as control hardware an instance of a given peripheral 
control. 

The ATM Application can then prompt the ATM user to swap to other 
sites by, for example, displaying buttons on the ATM screen which can be 
touched by the user to select a site. By swapping to other sites, for 
example, an Airline booking system site 70, the user can for example 
select a flight and pay for the flight directly from the ATM using the 
user's bank account information already stored in shared memory. Other 
sites could be utility company sites, at which the user could pay a bill, 
or supermarket sites 72, at which a user could cash in loyalty points* 
Thus, in one transaction a user, as well as inserting a credit card, 
could also insert an air miles card which can also be read by the ATM 
magnetic stripe reader. The user could cash in loyalty points for air 
miles at their supermarket site 72 and then swap to an airline site 70 
and pay for a ticket using these air miles, all without entering 
information more than once. 

It will be seen that, because several stages may be involved in any 
particular transaction using an ATM according to the invention, 
appropriate transaction processing methodology, for example two-phase 
commit, should be employed when updating resources such as a user's 
balance, air miles total etc* 

It will also be seen that the transaction processing system of 
either the model of Figure 1 or Figure 2 can operate with more than one 
application 10 at any given time or, in the case of a web ATM, many web 
applications can run through the web browser 80 along with conventional 
applications 10. Many wosa installations include sensitive peripherals, 
for example, an ATM includes a cash dispenser. If a rogue application 
were to gain access to the ATM, then it is possible that the application 
could, for example, instruct the cash dispenser to dump its contents. The 
application could read users account and pin information and print the 
information from the AIM printer or mail the information across the web. 
Such rogue activities are not limited to ATMs and it will be seen that 
this potential for fraud exists for any WOSA installation including 
sensitive equipment . 
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A security Service Provider Module (SPM) 95, Figure 5, enables a 
supervisor application to deny to other applications certain services 
provided by other peripheral SPMs controlling hardware. These SPMs would 
normally control sensitive devices in an Automated Teller Machine or 
kiosk, such as the Cash Dispensing unit, the Card Reader or Smart Card 
Reader, Pin Pad device. Depositor unit and Sensors and indicators unit. A 
supervisor application 10 or web application, running within the browser 
80, controlling the security module 95 can effectively lock access to 
these sensitive devices and restrict which other applications can gain 
access to them. This locking is over and above a conventional WOSA 
WFSLOCK command that is an optional command and can in any case be 
circumvented by a rogue application. 

The Security Module provides, inter alia, the following commands, 
15 . to the supervisor application: . _ „ 

RBGISTBB^SUPBRVTSOR UJ RPPIiICATION ( Process ID) returns a unique SA key 
for use in later commands. Process ID is the application registering as 
the Supervisor. 
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DBRBGISTBR^SUPBRVISOR^PPIiICATION (SA key) 



AI*LOVU)BVlCB_ACCBSS (SA key, HSKRVTCB, function code); and 
DISABL*J>BVICB_ACCBSS (SA key, HSBRVICB, function code) . 
Whenever an application issues a WFSOPEN command to a service 
provider module, a session handle HSBRVICB, is returned to the 
application. Function code may be one of the following, divided according 
to device: 

(Cash Dispenser Module) 

CDH.JHSPENSE 

CD*LJSET_TOTALS 
CDKJ5BTJCASHJUNITJDETAILS 

(Sensors and Indicators unit) 
SIU J)I SABLEL-SENSORS 
SIU_PI SABLELJ3VENTS 

(Deposit unit) 

DEP_RESETjCOUNTS 
(Identification Card Device Class) 

IDC_WRITE 
40 IDC_RESET_COUNTS 

IDC_CHIP_IO 
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PIN_JREAD_JCEYSTROKES 

The above commands are called as parameters for the WOSA wfsexecute 
command. 

CUKRY_i>BVICB_ J ACCBSS (SA key) returns HSERVICE. 

This function enables the SA to query the state of the various 
locks by issuing the command as a parameter for the WOSA wfsgetinfo 
command . 

In operation, an application 10 or a web application, pageiJL.htm, 
connecting to the Security Module 95 first registers itself as a 
Supervisor Application (SA) , ie the application that can make decisions 
on the accessibility of the various sensitive devices. The transaction 
processing system has a default startup setting of inactive, that is, 
anyone can get access to anything as per the normal rules of WOSA. Only 
one application can be registered as the Supervisor Application, any 
others attempting access will be rejected. Any other applications wishing 
to use sensitive devices must communicate with the supervisor application 
and request access to devices. 

Applications identify themselves to the supervisor application 
using HSERVICE and negotiate with the supervisor application in relation 
to the activities they wish to conduct in relation to sensitive devices* 
For example, an application may seek to be able to dispense cash from a 
cash dispenser and will thus need a level of access sufficient to call 
any cash dispensing functions. The mechanism by which the supervisor 
application negotiates the relevant permissions with other applications 
is not relevant to the current invention and can be conducted by any 
number of conventional techniques. 

Take, for example, a supervisor application and another application 
running within the model of Figure 1 or Figure 2. The supervisor 
application first calls: 

WFSBXECUTE (REGISTEf^SUPERVISOE*^APPLICATION(ProceSS ID) ) 

and receives an SA key. The other application opens access to a cash 
dispenser SPM using the WFSOPEN command and obtains a HSERVICE=1. The 
other application negotiates with the supervisor application to get 
access sufficient to set cash dispenser totals. The supervisor 
application then calls: 

WFSEXECUTB ( ALLOWED EVICE_ACC£SS {SA key, 1, CDM_SET_T0TALS) > 
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to update a table 97, Figure 1, with the appropriate information. The 
other application continues by making a call to the cash dispenser spm to 
dispense money. The cash dispenser SPM 30, or a filter 36 corresponding 
to a non-compliant cash dispenser SPM 37, receives the call from the WOSA 
manager, Figure 1, or through the server 40, Figure 2, and then checks 
with the security module 95 by passing the hsekvice identity of the 
application and the required function code to the security module. The 
security module then uses the internal table 97, Figure 1, to return 
negative to the SPM or filter, because the calling application does not 
have the required level of access. The SPM 30 or filter 36 will thus 
return WFS_JBRRJUNSUPPORTED._COMMAND to the application. The application 
will then need to negotiate with the supervisor application to obtain the 
appropriate access rights or be denied access. On the other hand, if the 
application were allowed access, then the filter 36 would pass the cash 
dispense call to the SPM 37 or the SPM 30 would execute as normal and 
respond accordingly to the application via the WOSA manager 20 or 
operating system messenger 50. 

in the model of Figures 2 and 3, the server 40 contains all 
compliant, device SPMs inside one single discrete entity. Any request to a 
device covered by the Security Module is checked by the device SPM 30 
running in the server 40 process. Figure 3, to see if the HSERVICE of the 
requesting application is allowed to call the target function. 

In the model of Figure 1 or where hardware vendors do not support 
the model of Figure 2, but their SPMS's 37 are written in the standard 
spm format, the service provider layer includes 'filter' DLLs 36 inserted 
between the WOSA manager and the vendor SPMs 37 . This is achieved by 
Windows NT Registry entries. Figure 4, that point both WOSA Manager 20 to 
the filter DLLs 36 and the filter DLLs to their associated SPM's 37. The 
filter DLLs 36 connect to both the vendor SPMs 37 and the Security Module 
95. Any commands passed through the WOSA Manager 20 from a calling 
application are checked by the filter DLLs 36 and either rejected or 
passed through to the original vendor SPM 37. The vendor SPM is unaware 
that anything has happened and takes no part in the checking procedure. 

In order for the security module to be operable from a web 
application, it must be compiled as an ActiveX Control or Javabean 
componet 95 residing on the local browser machine, for example, 
ATM#1. . .ATO#2, Figure 5. The control is instantiated from a web page 95', 
Figure 6, in the same manner as the shared memory control 60 and 
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peripheral control 90, to expose the methods described above to the 
calling web page. 

The above description discloses several controls 60, 90 and 95 
which can be instantiated from a web application. It will be seen that 
many variations of control may be developed to achieve different 
functions within a web application. 

For example, it is useful in a web ATM, for a web application to be 
able to determine if a transaction request has failed to complete within 
a given time. In a variation of Figure 5, the ATM includes a timer 
component (not shown) which can be instantiated from a web page in the 
same manner as the components 60, 90 and 95* The timer component exposes 
methods which enable an application to specify that it be notified after 
a given time lapse, and further after given time intervals. Thus, if an 
application requested the user to withdraw a card from the ATM card 
reader, a timer method could be called to notify the application after 
five seconds. If the application had not been notified of completion of 
the card with drawl, it could send a request to retract the card into the 
card reader. 

it is also useful for an application to be able to write error log 
or other similar information to the hard disk of the local machine in the 
event of serious failure or for statistical analysis purposes, it may 
also be desireable to enable an application to, for example, update or 
read entries in the windows registry. Figure 4. Other controls could 
therefore be provided to allow this functionality within a web 
application. 
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CLAIMS 

1. A transaction processing system for a web ATM including an internet 
browser adapted to run a web application, the web application comprising 
one or more web pages, said transaction processing system including: 

a transaction manager running in a first process; 

a peripheral controller component adapted to be instantiated from a 
web page, said peripheral controller including means for communicating 
transaction requests from said web application to said transaction 
manager ; and 

a set of service provider modules, each service provider module 
being adapted to relay transaction requests passed from said transaction 
manager to an associated hardware module. 

2. A transaction processing system as claimed in claim 1 wherein said 
peripheral controller component comprises: 

a first layer comprising means for enabling a web application to 
initiate a transaction request; and 

a second layer comprising means for dividing said transaction 
request into components and for communicating said transaction request 
components to said transaction manager. 

3. A transaction processing system as claimed in claim 2 wherein said 
first layer includes means for controlling an area of memory associated 
with said peripheral controller and means for selectively instantiating 
said second layer, on a first instantiation of the peripheral controller, 
said memory controlling means being adapted to control said area of 
memory to relay transaction request information to and from further 
instantiations of said peripheral controller. 

4. A transaction processing system as claimed in claim 2 wherein said 
second layer comprises means for communicating with an operating system 
messenger and for relaying operating system messages to said first layer. 

5. A transaction processing system according to claim 1: 
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a set of stub modules adapted to run in the same process as the 
transaction manager, each stub module being adapted to relay transaction 
request data passed from said transaction manager across a process 
boundary; 

a server adapted to run in a second process, said server being 
adapted to receive requests from said set of stub modules across the 
process boundary and to queue said requests for execution; 

each hardware module corresponding to a stub module and being 
responsive to said queued requests to convert said queued requests to 
respective hardware specific calls for a device associated with each 
hardware module. 

6. A transaction processing system as claimed in claim 5 wherein said 
transaction processing system is implemented on a windows NT operating 
system, said operating system including a windows registry, wherein said 
stub modules are implemented as stub dynamic link libraries which are 
adapted to be registered in the registry and wherein said transaction 
manager is adapted to call said stub DLLs by using information obtained 
by a lookup process performed on the Windows registry. 

7. A transaction processing system as claimed in claim € wherein said 
transaction manager is a Windows Open System Architecture (WOSA) manager, 
said transaction requests are WOSA calls and said manager is adapted to 
relay said WOSA calls to said server via said stub modules, said server 
being adapted to convert said WOSA calls into constituent components, 
each component corresponding to a low level generic hardware function 
call. 

8. A transaction processing system as claimed in claim 5, said system 
comprising: 

a second set of hardware modules, each hardware module of said 
second set being adapted to run in the same process as the transaction 
manager and being adapted to convert transaction requests passed from 
said transaction manager to respective hardware specific calls for a 
device associated with each hardware module of said second set. 
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9. A transaction processing system as claimed in claim 1 comprising a 
memory controller component being adapted to be instantiated from a web 
page, said memory controller component comprising: 

connect means adapted to check if a pre- determined area of shared 
memory has been allocated, and responsive to said shared memory not being 
allocated to allocate said shared memory; 

variable setting means adapted to allocate an area in shared memory 
for a variable and to store said variable; and 

variable retrieval means adapted to locate said variable in shared 
memory. 

10. A transaction processing system according to claim 9, wherein said 
memory controller includes: 

encryption key setting means adapted to store one or more 
encryption keys; 

variable encryption means adapted to allocate an area in shared 
memory for a variable and to store said variable in an encrypted format 
according to a pre -determined encryption key; and 

variable decryption means adapted to locate said variable in shared 
memory and to decrypt said variable according to said pre -determined 
encryption key. 

11. An Automatic Teller Machine (ATM) including the transaction 
processing system as claimed in claim 1, said ATM comprising: 

a. a processor connected to 

b. a memory, 

c. a screen display, 

d. a user input means, 

e. a card reader, and 

f . a storage medium, said storage medium being adapted to store 
said transaction processing system and operating system 
software, 

wherein said Internet browser is cooperable with said operating system 
software to display Internet web pages on said screen display and to 
receive user input from said user input means; and said peripheral 
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controller component comprises means for enabling an application to read 
data from a card inserted in said card reader and for communicating said 
data to said web application. 

12. An ATM as claimed in claim 11 comprising: 

a. a printer; and 

b. a cash dispenser ; 

wherein said peripheral controller comprises means for enabling an 
application to transmit transaction requests to said printer and said 
cash dispenser to said transaction manager. 

13* An ATM as claimed in claim 11 wherein said user input means 
comprise one or more of a numeric keypad, a set of function keys and a 
touch screen and said peripheral controller comprises means for enabling 
an application to transmit transaction requests for said keypad, function 
keys and/or said touch screen to said transaction manager. 

14. A peripheral controller component for a transaction processing 
system in which a transaction manager runs in a first process and is 
responsive to transaction requests from a browser adapted to run a web 
application, the application comprising one or more web pages, and a set 
of service provider modules are adapted to relay transaction requests 
passed from said transaction manager to an associated hardware module for 
execution; said peripheral controller component being adapted to be 
instantiated from a web page and including means for communicating 
transaction requests from said web application to said transaction 
manager. 



Amendments to the claims have been tiled as follows 



1. A transaction processing system for a web ATM including an Internet 
browser adapted to run a web application, the web application comprising 
one or more web pages, said transaction processing system including: 

a transaction manager running in a first process; 

a peripheral controller component adapted to be instantiated from a 
web page of the web application, said peripheral controller including 
means for communicating transaction requests from said web application to 
said transaction manager; and 

a first set of service provider modules, each service provider 
module being adapted to relay transaction requests passed from said 
transaction manager to an associated hardware module. ...... - ... 

2. A transaction processing system as claimed in claim 1 wherein said 
peripheral controller component comprises: 

a first layer comprising means for enabling a web application to 
initiate a transaction request; and 

a second layer comprising means for dividing said transaction 
request into components and for communicating said transaction request 
components to said transaction manager. 

3. a transaction processing system as claimed in claim 2 wherein said 
first layer includes means for controlling an area of memory associated 
with said peripheral controller and means for selectively instantiating 
said second layer, on a first instantiation of the peripheral controller, 
said memory controlling means being adapted to control said area of 
memory to relay transaction request information to and from further 
instantiations of said peripheral controller. 

4. A transaction processing system as claimed in claim 2 wherein said 
second layer comprises means for communicating with an operating system 
messenger and for relaying operating system messages to said first layer. 

5. A transaction processing system according to claim 1 further 
comprising: 
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a set of stub modules adapted to run in the same process as the 
transaction manager, each stub module being adapted to relay transaction 
request data passed from said transaction manager across a process 
boundary; 

a server adapted to run in a second process, said server being 
adapted to receive requests from said set of stub modules across the 
process boundary and to queue said requests for execution ; 

each service provider module of said first set corresponding to a 
stub module and being responsive to said queued requests to convert said 
queued requests to respective hardware specific calls for a device 
associated with each service provider module • 

6 . A transaction processing system as claimed in claim 5 wherein said 
transaction processing system is implemented on a windows NT operating - 
system, said operating system including a Windows registry, wherein said ^ 
stub modules are implemented as stub dynamic link libraries which are 
adapted to be registered in the registry and wherein said transaction 
manager is adapted to call said stub DLLs by using information obtained 
by a lookup process performed on the windows registry. 

7 . A transaction processing system as claimed in claim 6 wherein said 
transaction manager is a Windows Open System Architecture (WOSA) manager, 
said transaction requests are WOSA calls and said manager is adapted to 
relay said WOSA calls to said server via said stub modules, said server 
being adapted to convert said WOSA calls into constituent components, 
each component corresponding to a low level generic hardware function 
call . 

8. A transaction processing system as claimed in claim 5, said system 
comprising: 

a second set of service provider modules, each service provider 
module of said second set being adapted to run in the same process as the 
transaction manager and being adapted to convert transaction requests 
passed from said transaction manager to respective hardware specific 
calls for a device associated with each service provider module of said 
second set. 

9. A transaction processing system as claimed in claim 1 comprising a 
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memory controller component being adapted to be instantiated from a web 
page of the web application, said memory controller component comprising: 

connect means adapted to check if a pre -determined area of shared 
memory has been allocated, and responsive to said shared memory not being 
allocated to allocate said shared memory; 

variable setting means adapted to allocate an area in shared memory 
for a variable and to store said variable; and 

variable retrieval means adapted to locate said variable in shared 
memory. 

10. A transaction processing system according to claim 9, wherein said 
memory controller includes: 

encryption key setting means adapted to store one or more 
encryption keys; 

variable encryption means adapted to allocate an area in shared 
memory for a variable and to store said variable in an encrypted format 
according to a pre -determined encryption key; and 

variable decryption means adapted to locate said variable in shared 
memory and to decrypt said variable according to said pre -determined 
encryption key. 

11. An Automatic Teller Machine (ATM) including the transaction 
processing system as claimed in claim 1, said ATM comprising: 



a. 


a processor connected to 


b. 


a memory. 


c. 


a screen display. 


d. 


a user input means, 


e. 


a card reader, and 


f . 


a storage medium, said storage medium being adapted to store 
said transaction processing system and operating system 



software, 

wherein said internet browser is cooperable with said operating system 
software to display internet web pages on said screen display and to 
receive user input from said user input means; and said peripheral 
controller component comprises means for enabling an application to read 
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data from a card inserted in said card reader and for communicating said 
data to said web application. 

12. An ATM as claimed in claim 11 comprising: 

a. a printer; and 

b. a cash dispenser; 

wherein said peripheral controller comprises means for enabling an 
application to transmit transaction requests for said printer and said 
cash dispenser to said transaction manager* 

13. An ATM as claimed in claim 11 wherein said user input means 
comprise one or more of a numeric keypad, a set of function keys and a 
touch screen and said peripheral controller comprises means for enabling 
an application to transmit transaction requests from said keypad, 
function keys and/or said touch screen to said transaction manager. 

14. A peripheral controller component for a transaction processing 
system in which a transaction manager is responsive to transaction 
requests from a browser adapted to run a web application, the application 
comprising one or more web pages, and a set of service provider modules, 
each service provider module being adapted to relay transaction requests 
passed from said transaction manager to an associated hardware module for 
execution; said peripheral controller component being adapted to be 
instantiated from a web page of the web application and including means 
for communicating transaction requests from said web application to said 
transaction manager. 
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